【資料公開】PCI DSSのネットワークアクセス制御に関する要件とそのための実装を学ぶ勉強会をやりました（管理編）

中山（順）です

先日、PCI DSSにおけるパッチ管理をテーマにした勉強会を実施しました。

【資料公開】PCI DSSの認証取得を目指す方へ！AWSの利用を前提としたパッチ管理について考えるクローズドな勉強会をやりました

PCI DSS要件のある環境で自己管理の内部診断としてAmazon Inspectorを活用する方法

今回はその続きとして、ネットワークアクセス制御をテーマに勉強会を実施しました。 勉強会はテーマに関連するAWSの機能を解説し、その後ディスカッションする（AWSの機能が要件の充足にどの程度寄与しそうか、など）という流れで実施しました。

参加メンバーは前回と同様に弊社AWS事業本部コンサルティング部のメンバー ＋ とあるQSAの皆様です。

ネットワークアクセス制御自体の解説については、弊社岩城が担当しました。

【資料公開】PCI DSS 勉強会 ネットワークアクセス制御編

私はネットワークアクセス制御の設定を管理する方法について解説しました。

勉強会のスコープ

PCI DSSにおいて、ネットワークアクセス制御に関する要件は要件1にほぼ集約されています。

要件1.1では、ネットワークアクセス制御に関する設計（構成基準を定める）を行い、それを適切に実装することが求められています。 要件1.2および1.3ではどのようにアクセスを制御するべきかを定めています。（インターネットとDMZの通信を必要最低限度に制限すること／インターネットと内部ネットワークの直接の通信を制限すること） 今回の勉強会ではこれらの要件をスコープとしました。

要件1.4はシステムを管理するための端末からアクセスする際の要件を定めています。 また、要件1.5ではこれらを文書化して適切に運用することを定めています。 この部分については勉強会のスコープとしては除外しました。

勉強会で議論になりそうと想定したポイント

勉強会の準備をするにあたり、以下のような点が議論のポイントになるだろうと想定しました。 というより、私の中でこれらがうまく言語化できて整理できれば今回の勉強会は成功、という思いで臨みました。

• 非VPC（S3、Lambda、SQSなど）のサービスにおけるアクセス制御ってどう考えたらいいのか？
• AWSだけでできること/できないことは何か？
• ネットワークアクセス制御の重要性が相対的に下がっている？

資料

当日の解説で利用した資料はこちらです。

解説したこと

私のパートでは、「ネットワークアクセス制御に関する設計（構成基準）を実環境にどのように展開・管理すればいいか」をテーマとしていくつかの管理機能を解説しました。

AWSサービス

まず、関連しそうな以下のAWSサービスを紹介しました。

• CloudTrail
• Config
• CloudWatch Events
• Config Rules
• Security Hub
• CloudFormation

CloudTrail

AWSのAPI Callをロギングするサービスです。 誰が・いつ・何を・どこから実行したか、ということを特定できます。

Config

リソースに対して加えられた操作だけでなく、そのリソースの属性や他のリソースとの関連を管理してくれるサービスです。 いつ・どのような変更がリソースに加えられたのかを確認することができます。

Security Groupも管理対象のリソースとしてサポートされています。

Configを利用することで、以下の要件への対応に寄与できると思われます。（手作業で変更記録を取得する必要がない、など）

1.1.1.c ファイアウォールおよびルーター構成に実際に加えられた変更のサンプルを特定し、変更記録と比較して、責任者をインタビューして変更が承認されテストされたことを確認する。 Payment Card Industry（PCI） データセキュリティ基準　要件とセキュリティ評価手順　バージョン 3.2.1 2018 年 5 月

CloudWatch Events

Cloudwatch Eventsは、各種イベントをトリガーに何らかの処理を実行できるサービスです。 Security Groupの変更をトリガーにすることが可能です。

先ほど示した要件1.1.1.cは、「変更が承認され」たものであることの確認を求めています。 全ての変更を通知することで承認していない変更に気がつくことができるかもしれません。 ディスカッションにおいても改ざん/不正な変更への対策として有効な機能ではないかとの評価がありました。

Config Rules

Config RulesはAWSリソースが基準に則った構成であることを検出し、必要に応じて是正することができるサービスです。

例えば、以下のルールを利用することで指定したポート以外を利用していることを検出することができます。

vpc-sg-open-only-to-authorized-ports

また、以下のルールを利用することにより、デフォルトのSecurity Groupで既定の許可が削除されていることを検出できます。 これにより、暗黙的な許可を与えてしまうリスクを排除できるでしょう。（要件1.2.1.cへ寄与）

vpc-default-security-group-closed

1.2.1.c ファイアウォール/ルーター構成を検査して、例えば明示の「すべてを拒否」、または許可文の後の暗黙の拒否を使用することで、他のすべての着信および発信トラフィックが明確に拒否されていることを確認する。 Payment Card Industry（PCI） データセキュリティ基準　要件とセキュリティ評価手順　バージョン 3.2.1 2018 年 5 月

Security Hub

Security Hubは各種セキュリティイベントの情報を集約する、文字通りのハブとなるサービスです。

また、Security Hub自身もAWSリソースの構成を特定の基準に基づいて検査することができます。 現時点では、CIS Benchmarkをサポートしています。

Standards Supported in AWS Security Hub: CIS AWS Foundations

様々なルールが定義されていますが、以下のルールではSecurity Groupの変更を検知および通知することが求められています。

3.10 – Ensure a log metric filter and alarm exist for security group changes

ディスカッションでは、「Trusted Advisorとの違いは？」という質問がありました。 精密な確認はしていませんが、Security HubのCompliance standardsでチェックできることはTrusted Advisorのセキュリティに関するチェック項目を包含しているかと思います。

Trusted Advisor ベストプラクティス (チェック)

CloudFormation

AWSリソースをコード化するためのサービスです。 JSONもしくはYAMLでインフラの「あるべき状態」を定義し、その通りのリソースをプロビジョニングできます。 この際、リソースの作成手順は（ほぼ）意識する必要がありません。

インフラをコード化することで、以下のことが容易にできるようになります。

• プロビジョニング前にコードレビューを行うことができる（プロビジョニング前に承認を求めることができる）
• 本番環境と同じ構成のAWSリソースを検証環境としてプロビジョニングできる（テストを行うことができる）

これは、CloudFormationを運用に組み込むことで以下の要件に寄与できるのではないかと考えました。

1.1.1.a 文書化された手順を調べて、すべてをテストし承認するための正式なプロセスがあることを確認する。
- ネットワーク接続および
- ファイアウォール/ルーター構成の変更 Payment Card Industry（PCI） データセキュリティ基準　要件とセキュリティ評価手順　バージョン 3.2.1 2018 年 5 月

1.1.1.b ネットワーク接続のサンプルでは、責任者をインタビューし、記録を検査してネットワーク接続が承認されてテストされていることを確認する。 Payment Card Industry（PCI） データセキュリティ基準　要件とセキュリティ評価手順　バージョン 3.2.1 2018 年 5 月

また、CloudFormationテンプレートが構成基準に準拠しており、なおかつ変更手順にCloudFormationが組み込まれていることが前提条件として成立するのであれば、 Driftを利用することで不正なルール（マネージメントコンソールなどから加えられたルール、など）を容易に発見できます。 （Driftが無いだけでは実環境が構成基準に基づいて設定されていることを担保できない＝構成基準がCFnテンプレートに反映されていることを担保する必要がある）

Detecting Unmanaged Configuration Changes to Stacks and Resource

IAM

IAMは、ユーザー認証および認可（権限管理）を司るサービスです。 これ自体は構成管理機能ではありませんが、当然適切な管理者のみが構成の変更を行えるべきです。 実際、以下のような要件が定められています。

1.1.5.b ネットワークコンポーネントの管理責任者をインタビューし、文書通りに役割と責任が割り当てられていることを確認する。 Payment Card Industry（PCI） データセキュリティ基準　要件とセキュリティ評価手順　バージョン 3.2.1 2018 年 5 月

小まとめ

ここまでで、要件1.1への対応に寄与できそうな機能を紹介してきました。

しかし、以下の要件は標準の要件での対応が難しそうです。

まず、AWS上に構築したシステムのネットワーク構成の「全体像」を皆さんはどのように管理していますか？ 少なくとも自動でネットワーク構成図を出力する機能はありません。

1.1.2 ワイヤレスネットワークなど、カード会員データ環境とその他のネットワーク間のすべての接続を示す最新ネットワーク図 Payment Card Industry（PCI） データセキュリティ基準　要件とセキュリティ評価手順　バージョン 3.2.1 2018 年 5 月

1.1.3 システムとネットワーク内でのカード会員データのフローを示す最新図 Payment Card Industry（PCI） データセキュリティ基準　要件とセキュリティ評価手順　バージョン 3.2.1 2018 年 5 月

また、利用しているプロトコルが安全かどうかの判断もできません。（評価ルールをユーザー自身で定義できれば、Config Rules等で実装することはできます）

1.1.6 安全でないと見なされているプロトコルに実装されているセキュリティ機能の文書化などを含む、使用が許可されているすべてのサービス、プロトコル、ポートの使用に対する業務上の正当な理由および承認の文書化 Payment Card Industry（PCI） データセキュリティ基準　要件とセキュリティ評価手順　バージョン 3.2.1 2018 年 5 月

ということで、これを補完できそうなサードパーティのサービスであるDome9を解説しました。

Dome9

紹介した機能は以下の機能です。

• Clarity(Network Security)
• Rulesets(Compliance & Governance)

Clarity(Network Security)

Clarityは、Security Groupを可視化するサービスです。 個別のルールを確認できるだけでなく、リソース間の関連／ネットワークの全体像を可視化できます。

機能の詳細はこちらです。

Dome9でSecurityGroupを可視化してみた

こちらは、監査時のエビデンスにはなり得ないものの、監査や運用時のサポートツールとしては非常に有用そうとのコメントがありました。 例えば、実際の設定が構成基準に則っているかを確認したり、外部スキャンの対象（公開サーバー）の特定を容易に行うことができます。

Rulesets(Compliance & Governance)

Compliance & Governanceは、AWSリソースの構成がセキュリティ標準に則っているかを検査することができます。 Config RulesのマネージドルールやSecurity HubのCompliance standardsと機能としては類似しています。 しかし、デフォルトで提供されているルールが非常に豊富です。

サポートされているセキュリティ標準は以下のドキュメントで確認できます。

Compliance Engine Rulesets & Rules

また、提供されている具体的なルールは以下のサイトで確認できます。

CLOUD SECURITY POSTURE REPOSITORY (CSPR)

この中には、SSHやRDP以外のいくつかの管理ポートで任意のIPアドレスからアクセス可能であることを検出できます。

Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to administrative ports ports. SECURITY GROUPS - WITH ADMIN PORTS TOO EXPOSED TO THE PUBLIC INTERNET

機能の詳細はこちらです。

Dome9で継続的なセキュリティチェックを実行する

まとめ

以上のように、多くのPCI DSS要件を効率的に実現するために、AWSの機能をサポートツールとして活用することが可能であるという考えに至りました。 しかし、AWSの機能だけではカバーできていない領域があることもはっきりしました。 必要に応じてコストも勘案しながらサードパーティーサービスの活用を検討するといいでしょう。

また、当たり前のことですが適切な構成基準は設計者が作成する必要があります。 これ自体は自動化することはできません。 CloudFormation等で設計した内容を実際の環境に正しく適用しやすくすることはできますが、設計の正しさは人にしか評価できません。 故に、人じゃなくてもできることはサービスに任せたいものです。